Network Address Translation (NAT) is the simplest way of accessing an external network from a virtual machine. Usually, it does not require any configuration on the host network and guest system. For this reason, it is the default networking mode in VirtualBox.
A virtual machine with NAT enabled acts much like a real computer that connects to the Internet through a router. The "router", in this case, is the VirtualBox networking engine, which maps traffic from and to the virtual machine transparently. The disadvantage of NAT mode is that, much like a private network behind a router, the virtual machine is invisible and unreachable from the outside internet; you cannot run a server this way unless you set up port forwarding (described below).
The virtual machine receives its network address and configuration on the private network from a DHCP server that is integrated into VirtualBox. The IP address thus assigned to the virtual machine is usually on a completely different network than the host. As more than one card of a virtual machine can be set up to use NAT, the first card is connected to the private network 10.0.2.0, the second card to the network 10.0.3.0 and so on. If you need to change the guest-assigned IP range for some reason, please refer to Sectioná9.11, “Configuring the address of a NAT network interface”.
The network frames sent out by the guest operating system are received by VirtualBox's NAT engine, which extracts the TCP/IP data and resends it using the host operating system. To an application on the host, or to another computer on the same network as the host, it looks like the data was sent by the VirtualBox application on the host, using an IP address belonging to the host. VirtualBox listens for replies to the packages sent, and repacks and resends them to the guest machine on its private network.
As the virtual machine is connected to a private network internal to VirtualBox and invisible to the host, network services on the guest are not accessible to the host machine or to other computers on the same network. However, VirtualBox can make given services available outside of the guest by using port forwarding. This means that VirtualBox listens to certain ports on the host and resends all packages which arrive on them to the guest on the ports used by the services being forwarded.
To an application on the host or other physical (or virtual) machines on the network, it looks as though the service being proxied is actually running on the host (note that this also means that you cannot run the same service on the same ports on the host). However, you still gain the advantages of running the service in a virtual machine -- for example, services on the host machine or on other virtual machines cannot be compromised or crashed by a vulnerability or a bug in the service, and the service can run in a different operating system to the host system.
You can set up a guest service which you wish to proxy using the
command line tool VBoxManage. You will
need to know which ports on the guest the service uses and to decide
which ports to use on the host (often but not always you will want to
use the same ports on the guest and on the host). You can use any ports
on the host which are not already in use by a service. An example of how
to set up incoming NAT connections to a
ssh server on the guest requires the
following three commands:
VBoxManage setextradata "Linux Guest"
"VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestssh/Protocol" TCP
VBoxManage setextradata "Linux Guest"
"VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestssh/GuestPort" 22
VBoxManage setextradata "Linux Guest"
"VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestssh/HostPort" 2222The above example assumes a PCNet virtual network card; if you have configured the guest to use the Intel PRO/1000, replace "pcnet" with "e1000" in the above commands.
The name guestssh is an arbitrary
one chosen for this particular forwarding configuration. With that
configuration in place, all TCP connections to port 2222 on the host
will be forwarded to port 22 on the guest.
Protocol can be either of
TCP or
UDP (these are case insensitive). To
remove a mapping again, use the same commands, but leaving out the
values (in this case TCP,
22 and
2222).
It is not possible to configure incoming NAT connections while the VM is running. However you can change the settings for a VM which is currently saved (or powered off at a snapshot).
PXE booting is now supported in NAT mode. The NAT DHCP server
provides a boot file name of the form
vmname.pxe if the directory
TFTP exists in the directory where the
user's VirtualBox.xml file is kept. It
is the responsibility of the user to provide
vmname.pxe.
There are four limitations of NAT mode which users should be aware of:
Some frequently used network debugging tools (e.g.
ping) rely on sending/receiving
messages based on the ICMP protocol. The ICMP protocol cannot be
used directly by normal applications such as VirtualBox, as it
would, at least on Linux hosts, require root permissions (more
precisely CAP_NET_RAW). Since this is not desirable, no attempt
has been made to support ICMP to addresses other than 10.0.2.2 and
10.0.2.15. If you try to ping any other IP address you will not
get any response.
The guest does not reliably receive broadcasts, since, in
order to save resources, it only listens for a certain amount of
time after the guest has sent UDP data on a particular port. As a
consequence, NetBios name resolution based on broadcasts is not
always working (but WINS always works). As a workaround, you can
use the numeric IP of the desired server in the
\\server\share notation.
Protocols other than TCP and UDP are not supported. This means some VPN products (e.g. PPTP from Microsoft) cannot be used. There are other VPN products which use simply TCP and UDP.
On Unix-based hosts (e.g. Linux, Solaris, MacOS X) it is not
possible to bind to ports below 1024 from applications that are
not run by root. Therefore if you
try to configure such a port forwarding, then the VM will refuse
to start.
These limitations normally don't affect standard network use. But the presence of NAT has also subtle effects that may interfere with protocols that are normally working. One example is NFS, where the server is often configured to refuse connections from non-privileged ports (i.e. ports not below 1024).